United States Patent m 

Bernstein et ai. 



illllllllllllllll 

US0052O4947A 

[i l] Patent Number: 5,204,947 
[45] Date of Patent: Apr. 20, 1993 



[54] APPLICATION INDEPENDENT (OPEN) 
HYPERMEDIA ENABLEMENT SERVICES 

[75] Inventors: Keith Bernstein, Washington, D.C.; 

John A. Stephens, Bo yds, Md. 

[73] Assignee: International Business Machines 
Corporation, Armonk, N.Y. 

[21] Appl. No.: 606,320 

[22] Filed: Oct. 31, 1990 

[51] Int.CL' G06F3/14 

[52] US. Q 395/157; 395/154; 

340/716 

[58] Field of Search 364/DIG. 1, DIG. 2; 

340/709, 710, 716, 717, 718, 720, 724; 395/154, 
155, 157, 159, 160, 161, 158 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,692,757 9/1987 Tsuhara et al 340/721 

4,893,256 1/1990 Rutherfoord et al 395/154 

4,914,586 4/1990 Swinchart ct al 395/600 

4,931,950 6/1990 Isle et al 395/11 

4,982,344 1/1991 Jordan 395/157 

FOREIGN PATENT DOCUMENTS 

88119250 of 0000 European Pat. Off. . 

OTHER PUBLICATIONS 

"Hypertext II" by Jakob Nielsen. SICCHI Bulletin, 
Oct. 1989 vol 21, No. 2 pp. 41-47. 



"Hyperhyper" by Jakob Nielsen, SIGCHI Bulletin vol. 
21, No.. 1, Feb. 1989, pp. 65-67. 
"Trip Report: Hypertext '89 M by Jakob Nielsen SIG- 
CHI Bulletin vol. 21, No. 4, Apr. 1990, pp. 52-61. 
"Sun's Link Service: Protocol For Open Linking 1 ' by 
Amy Pearl , Hypertext % 89 Proceedings Nov. 1989, pp. 
137-146. 

"An overview of Hypertext & Hypermedia" Concepts <£ 
Issues EP10-010-701 Nov. 1989. 
"Multimedia Authoring Systems" PC Magazine Jul. 
1990, pp. 163-192. 

Desktop Multimedia: "You Ain't Seen Nothing Yet" by 
Eric Bender, PC World Mar. '90, pp. 191-196. 
"Hypeted" by Steven Ditlea, PC/Computing Oct. 1990, 
pp. 201-210. 

Primary Examiner— Robert L. Richardson 
Attorney, Agent, or Firm — Whitham & Marhoefer 



[57] 



ABSTRACT 



A set of hypermedia linking services enable client appli- 
cations to incorporate hypermedia capabilities in an 
open system architecture. The users are provided with 
a consistent hypermedia interface completely managed 
by the hypermedia services and not by the client appli- 
cation itself. The graphical user interface includes meth- 
ods for menu handling, dialog box presentation and 
pointing device message handling, e.g., mouse message 
handling. Normal hypermedia activities such as object 
management, object creation, object deletion and object 
modification is provided. 

48 Claims, 24 Drawing Sheets 
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These objects include audio files, motion video files and 

APPLICATION INDEPENDENT (OPEN) clips, and a series of image files (i.e., slide shows). 

HYPERMEDIA ENABLEMENT SERVICES End User Interface (EUI): The methodology, include 

ing devices, by which an end user interacts with a sys- 

CROSS-REFERENCE TO RELATED 5 tern, system component, and/or system application. 

APPLICATION Graphical User Interface (GUI): An EUI which is 

The invention disclosed in this application is related « ra P hicaI . ; for example, end user interactions' with the 

in subject matter to application Ser. No. 273,527 filed S f tem Via Vflndov ^ lcons ' menus > ^° mtm & devic «. 

Nov, 1 8 ,1988, by P. Y. Chang etal. and assigned to the in j • » « . . t 

assignee of this application. The disclosure of the fore- 10 ^V*™ «lit: In the genencand simplest 

going application is incorporated herein by reference. W these terms mean touch and get. They embody 

6 * yr ^ ' the notion of an end user being able to touch (e.g., using 

DESCRIPTION some kind of pointing device) an object (e.g., a word, 

BACKGROUND OF THE INVENTION lf S^^^- 0 ^^ ^v*^ °w °l 

15 more associated information entities to be obtained. A 

L Field of the Invention survey of hypertext systems is provided in •'Hypertext: 

The present invention generally relates to a software An Introduction Survey" by Jeff Conklin, IEEE Com- 
facility for providing relatively seamless integration of puter, September 1987, pp. 17-41, and "An Overview of 

"hypertext/hypermedia** services into existing, as well Hypertext and Hypermedia", Concepts & Issues, 

as new, computer program applications and, more par- 20 McGraw-Hill, November 1989. 

ticularly, to support for an end user interface, link and Link: An object which associates a point in one docu- 

link marker authoring, link navigation and link marker ment with a point in another document (or different 

abstracts, using an open system architecture. This in- P oint in the same document). Links may be bidirectional 

eludes support for the end user interface as well as and therefore may be followed from either end. 

storage in a database. 25 Li °k Manager Services (LMS): A complete inte- 

2. Definition of Terms grated set of hypertext/hypermedia services. 

The following terminology is used throughout this Lin k marker: A (typically) visual indication to the 

disclosure. user » contained within a document, indicating that 

Abstract: A text object consisting of keywords, there may be one or more links present at this point (the 

phrases, and/or statements, which summarize the im- 30 lmk marker's location) in the document. If there are 

portant information that would be found at a link hnks emanating from a link marker and the link marker 

marker with which the text object is associated. IS triggered (e.g., by the end user with a mouse), the link 

Application: A computer program, other than an mar 1 ker 5 } inks m ^ be navigated. LMS provides link 
operating system, such as a word processor, spread- , ma [ kers , can *» ave manv <Wfcrem appearance styles, 
sheet, database management, graphics designer, and the 35 ^eluding (1) push-buttons which may optionally con- 
like. As-used herein, an application program -is-also - Barnes which all^w the end usej- to . 
referred to as a presenter. see hrou ^ the l mk marker ^framed area to the client 

Application Programming Interface (API): A means application s underlying rendered data, (3) highlight 

by which a program may call a service. ^ ^« like black frames . provide for transpar- 

, v *■ a r *• / ♦ / ^ 40 en cy, but which have frames which are guaranteed to 

rS?l!c?S^S «fv£ ™ (pTeSenXeT/pr0 ' be visible (particularly useful compared to black frames 

gram) which uses LMS services when some ofthe underlying data may be black or very 

Context menu: Often referred to as popup menus, ^ (4) ^ fc area s wLh are also transparent in 

context menus are visually and functionally similar to ^ the ms of ^ under , m Qata wil] } J disGm ^ 

pull-down menus, but are not tied to the action or com- 45 fW bm thg colors of ^ un( f erl k data ^ ^ 

mand bar. They may appear at arbitrary positions in cha d (aUo sometimes ^ovm ^ rev * se ^ 

windows. Additionally, while the contents of a pull- a]] under i ying black is changed t0 whitC( aJ| wh f te 

down menu typically do not change based on the state ^ i$ changed t0 bIack> ^ blue color fa ch d t0 

of the application at any given time (though they may yeHoW( ^ an(J (5) invisible which m tru]y mvisiblc 

be enabled or disabled/grayed), the contents of a con- 50 with regard t0 ^ occlusion of the underlying data, 

text menu, on the other hand, are dynamic, and change Mouse: The term mouse, when used in this document, 

based on the state of the application; in other words, rea ji y refers t0 any type of operating system supported 

they are context sensitive. For instance, if a context pointing device including, but not limited to a mouse, 

menu contained an item which said, "Save", when the ball, lightpen, touch screen, and the like. Also, the 

context menu is displayed and no data has been modi- 55 screens, keyboard and mouse operations, menus, etc. 

fled, the "Save" option would not appear in the menu. with which an end-user interacts with when using an 

Context menus are typically displayed when the end application. 

user clicks a mouse button over some window. Context Navigation: The following, or traversal, of a link, 

menus typically contain similar function to pull-down Open system: A hypermedia system which allows 

menus, but only include those items which are relevant 60 any application (presenter) to participate in linking, 

to the object clicked on, at a given time. Such applications need not be aware of documents and- 

Document: A named set of data (such as a text file, an /or presenters at the other ends of links, thus allowing 

image file, a video passage, etc.) usually, but not neces- for the seamless integration of applications and applica- 

sarily, discernible by an end user (when rendered by a tion-rendered data developed totally independently 

presenter). Thus, the term "document" is not limited to 65 from one another. 

a text file but may be text, bitmap graphics, a spread- Presenter: An application which renders data (e.g., 

sheet or some other data presentation. In some cases, text files, image files, audio passages, etc.) for an end 

other objects are considered as "documents" by LMS. user. 
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Pull-down menu: These are the menus which are tied plied) applications (presenters) with hypermedia capa- 

to the action bar (menu bar) at the top of a window. bilities. 

These menus may also contain submenus, which are Sun Link Service by Sun Microsystems is the only 

known as cascade menus. other open hypermedia system known to the inventors 

2. Description of the Prior Art 5 as an available product. Sun's facility does provide a set 

A number of hypertext/hypermedia systems are pro- of services which allow other (non-Sun-supplied) appli- 

grammed in an object-oriented programming language, cations to be enabled with hypermedia capabilities; 

such as Smalltalk and C++. The former was devel- however, this enablement is neither seamless nor easy, 

oped at the Xerox Palo Alto Research Center (PARC), Additionally, the Sun Link Service does not manage the 

and a good description of that language may be had by 1° end user interface for the hypermedia capabilities, 

reference to the textbook by Adele Goldberg and which means that each application must implement its 

David Robson entitled Smalltalk-ZO: The Language and own n ° tion in that regard. Additional information on 

Its Implementation, Addison-Wesley, 1983. The C+ + product may be found in an article entitled "Sun's 

language was developed by Bjarne Stroustrup of Link Service: A Protocol for Open Linking" by Amy 

AT&T Bell Laboratories and described, for example, in 15 Pcarl on P a S es 137-146 of the Hypertext^ Proceedings, 

his book entitled The C++ Programming Language, In addition to the foregoing, several other products 

Addison-Wesley, 1986. Among the advantages of Ob- which ™Plement hypertext/hypermedia capabilities 

ject-Oriented Programming Systems (OOPS) are mod- were reviewed in the October I990issue of PC/ Com - 

ular structure and object-oriented user interfaces using ***** *{qpmnt &l pages 201-210. Tnese include Folio 

icons. Further information on object oriented program- 20 V^ws 2.0 by Folio Corp., Hy^rties by Cognetics 

ming and hypersystems may be obtained from "Design C°rp., HyperWnter by Ntergaid, Spinnaker Plus IX) by 

and Use of Hyperdedia Systems" by Robert Akscyn of ^^ v So ^ m Cw P-. Tra * s A text , by M ? X ' 

Knowledge Systems, Inc., Conference on Human Fac- Fo,, ° V,e f WS ^ reviewed as: "An information 

tors in Computing Systems, May 14, 1988, and "Interme- „ ™»«™ system that ets you compress large text 

— , / * / . ~ cf ' ; ' n ? x n r»k;.^ 25 mt0 a customized 'mfobase' and create cross- 

dia: The Architecture and Construction of An Object referencin links „ Notnin furthef is knQWn of ^ 

Onen ed Hypermedia System and Apphcanon Frame- £ ^ 

WOr nn^T n Meyrowitz IRIS. Brown Umver- allow for linking between different presenters and- 

sity, OOPSLA Proceedings, September 1986. /qt diffcrcm of 6m ^ alsQ ^ QO 

Insofar as the inventors are aware, there are no M method is ide<J for ^ ^ (non-Folio 

hypertext/hypermedia systems, or system services, views-supplied) applications (presenters) with hy- 

which enable applications (presenters) to seamlessly and pennedia capabilities. 

easily incorporate hypertext/hypermedia capabilities m Hyperties was reviewed as: "An interactive system 

an open system architecture, as well as automatically that , ets you create hypertext documents and manuals 

provide a consistent end user hypermedia interface 35 f rom a variety of media, including existing files, online 

which is managed by the hypermedia services, and not information, scanned material and video." Hyperties is a 

the presenter itself. Additionally, even those hy- dosed hypermedia system; e.g., one must use only the 

permedia systems which are somewhat "open" systems presentation facilities supplied by the product Nothing 

cannot alter the user interface upon future releases with- further ^ known of ^ product( however, the review 

out requiring all hypermedia applications in the system 40 sug gests that no method is provided for enabling other 

to be modified and rebuilt. (non-Hyperties-supplied) applications (presenters) with 

The prior art discussed below are representative of hypermedia capabilities, 

products and/or services which implement hypertex- HyperWriter was reviewed as: "A hypertext author- 

t/hypermedia capabilities. m g tool with audio and video capabilities and a limited 

HyperCard published by Apple Corp. is considered 45 scripting language." 
by many (including its author, Bill Atkinson) to not be Spinnaker Plus 2.0 was reviewed as :"A hypertext 
a hypermedia product, but rather an "application programming environment for developing and running 
builder" or "stack of cards". When viewed as a hy- custom information management applications." Al- 
permedia system (in that cards are "linked" together) it though no more information than this is known, it ap- 
is a closed hypermedia system; e.g., one must use only 50 pears from the review that Spinnaker is more of an 
the presentation facilities supplied by the product. Hy- application generator program than a "true" hypertext 
perCard provides no facility for enabling other (non- product. 

HyperCard-supplied) applications (presenters) with Transtext was reviewed as: "A word processor that 

hypermedia capabilities. lets you create hypertext links to many other commer- 

The SuperCard program by Silicon Beach Software 55 daily available applications." Nothing further is known 

is a HyperCard "look-alike", with more power than 0 f this product, however, the review seems to indicate 

HyperCard. It provides stacks of "cards", as well as that unidirectional links out of the product may be es- 

application generation. Other examples of closed hy- tablished, which probably simply cause the launching of 

permedia systems include Guide 2,0 by OWL Interna- existing commercially available applications, simply 
tional, Inc. which provides no facility for enabling other 60 passing them user-specified parameters. 

(nonGuide-supplied) applications (presenters) with hy- In addition, KnowledgePro by Knowledge Garden, 

permedia capabilities; IRIS Intermedia by Institute for Inc., was reviewed in the November 1989 issue of Con- 

Research in Information and Scholarship ORIS), cepts & Issues, referenced above, as; **. . . while some 

Brown University, which also provides no facility for skill in programming is useful in becoming familiar with 

enabling other (non -Intermedia-supplied) applications 65 the product, its developers claim such skill is not a 

(presenters) with hypermedia capabilities; and Link- prerequisite to learning the program ... a programming 

Way 2.0 by IBM Educational Systems and which pro- environment that combines an expert system generator 

vides no facility for enabling other (non-LinkWay-sup- with hypertext ... It can read external files, call external 



03/02/2004, EAST version: 1.4.1 



5,204,947 



20 



programs, and be extended by routines written in other 
languages." In addition, the review also suggests that 
the programming environment/expert system generator 
combination could yield some sophisticated searching 
capabilities. However, nothing more specific is known 5 
either about the search capabilities or the degree of 
openness contained in the product. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to 10 
provide a set of system linking services, which enable 
applications (presenters) to seamlessly and easily incor- 
porate hypertext/hypermedia capabilities in an open 
system architecture, as well as automatically provide 
end users with a consistent hypermedia interface which 15 
is completely managed by the underlying linking ser- 
vices and not the presenter itself. 

It is a more specific object of the invention to provide 
a consistent set of menus and dialog boxes for client 
applications which are built by the hypermedia system 
independent of the applications. 

It is yet another object of the invention to provide an 
end user with a link marker facility to identify the loca- 
tion of one or more links at a given point in a document. 

It is still another object of the invention to provide an 
invisible or transparent windowing procedure of gen- 
eral utility. 

According to the invention, an end user interface 
management provides a consistent end user interface ^ 
across all client applications for hypermedia menus, 
dialog boxes, mouse processing, and link marker display 
management. These facilities not only provide for the 
appearance of these notions, but also result in the execu- 
tion of code to semantically satisfy the end user's re- 35 
quest. One of the primary methods of interaction be- 
tween an end user and a program (in a GUI environ- 
ment) is through the use of menus. Menus, therefore, 
become a primary vehicle through which an end user 
accesses a program's functionality. In most applications, ^ 
menu management is an arduous task, often producing 
an inconsistent EUI across applications. The menu sup- 
port provided by LMS solves this problem by managing 
the building and maintenance of menus. LMS will also 
perform all functions contained within the menu with- 45 
out requiring any client application involvement. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advan- 
tages will be better understood from the following de- 50 
tailed description of a preferred embodiment of the 
invention with reference to the drawings, in which: 

FIG. 1 is pictorial representation of a personal com- 
puter; 

FIG. 2 is a system block diagram of the personal 55 
computer shown in FIG. 1; 

FIG. 3 is a functional block diagram of the link man- 
ager services implemented on the personal computer 
shown in FIGS. 1 and 2; 

FIG. 4A is a block diagram illustrating a marker to 60 
object (unidirectional) link, and FIG. 4B is a block 
diagram illustrating a marker to marker (bidirectional) 
link; 

FIG. 5 is a block diagram showing the functional . 
relationship of Link Manager Services in an open sys- 65 
tern; 

FIG. 6 is a flow diagram showing the logic of the 
client application window procedure; 



FIG, 7 a screen showing a document and marker 
before navigation; 

FIG. 8 is a screen showing a new document and 
marker after navigation; 

FIG. 9 is a screen showing a context menu when a 
mouse has been clicked on a document; 

FIG. 10 is a screen showing a context menu when a 
mouse has been clicked on a link marker; 

FIG. 11 is a screen showing a pull-down menu when 
a mouse has been clicked on LINK in the command bar; 

FIG. 12 is a screen showing a second pull-down 
menu when a mouse has been clicked on MANAGE 
MARKERS in the first pull-down menu of FIG. 11; 

FIG. 13 is a screen showing a third pull-down menu 
when a mouse has been clicked on CREATE 
MARKER in the second pull-down menu of FIG. 12; 

FIG. 14 is a screen showing a second pull-down win- 
dow when a mouse has been clicked on MANAGE 
LINKS in the pull-down window of FIG. 11; 

FIG. 15 is a screen showing a third pull-down win- 
dow when a mouse has been clicked on CREATE 
LINK in the second ,pull-down window of FIG. 14; 

FIG. 16 is a flow diagram showing the logic of the 
pull-down menu processing performed by LMS; 

FIG. 17 is a flow diagram showing the logic of the 
context menu processing performed by LMS; 

FIG. 18 is a flow diagram showing the logic of the 
non-menu command message processing performed by 
LMS; 

FIG. 19 is a flow diagram showing the logic of the 
create marker procedure performed by LMS; 

FIG. 20 is a flow diagram showing the logic of the 
marker window procedure performed by LMS; 

FIG. 21 is a flow diagram showing the logic of the 
window painting procedure which supports transparent 
or invisible windows; 

FIG. 22 is a screen print showing the location of an 
invisible marker (i.e., window) by reverse video high- 
lighting; 

FIG. 23 is a screen showing multiple, overlying win- 
dows to illustrate the procedure normally followed 
when a window is painted on the screen; 

FIG. 24 is a screen showing an example of an LMS 
dialog box for selecting a link marker style; 

FIG. 25 is a screen showing another example of an 
LMS dialog box for managing links; 

FIG. 26 is a screen showing a third example of an 
LMS dialog box for initiating a search of the LMS 
hypermedia database; 

FIG. 27 is a flow diagram showing the logic of the 
dialog box management procedure performed by LMS; 

FIG. 28 is a flow diagram showing the logic of the 
LMS database update procedure; 

FIG. 29 is a flow diagram showing the logic of the 
link marker and link database update procedure called 
by the'procedure shown in FIG. 28; and 

FIG. 30 is a block diagram showing the functional 
relationships between LMS, an application and the 
EUI. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT OF THE INVENTION 

The invention may be run on a variety of computers 
under a number of different Operating Systems (OS). 
The computer could be, for example, a personal com- 
puter, a mini computer or a main frame computer. The 
computer may a standalone system, part of a network 
such as a Local Area Network (LAN) or Wide Area 
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Network (WAN) or a larger teleprocessing system. For 28 provides the hardware interface for the keyboard 12, 
purposes of illustration only, the invention is described the mouse controller 29 hardware interface for the 
below as implemented on a persona) computer, such as mouse 13, and the video controller 30 provides the 
IBM's PS/2 series, although the specific choice of com- hardware interface for the graphic display device 14. 
puter is limited only by memory and disk storage re- 5 The hardware illustrated in FIGS. 1 and 2 is typical 
quirements. For additional information on IBM's PS/2 but may vary for a specific application; that is, there 
series of computers, the reader is referred to Technical may be other peripherals, such as optical storage media, 
Reference Manual Personal System/2 (Model 50, 60 Sys- audio I/O, printers and the like. The invention is specifi- 
tems), IBM Corporation, Part No. 68X2224, Order No. cally directed to an enhancement to the Operating Sys- 
S68X-2224, and Technical Reference Manual Personal 10 tern (OS) which controls or "runs" the hardware. As 
System/2 (Model 80), IBM Corporation, Part No. mentioned, the invention may be added to an existing 
68X2256, Order No. S68X-2256. OS or it may be integrated into the OS, but it will be 

The operating system on which a preferred embodi- assumed for purposes of this disclosure that the* OS 
ment of the invention was implemented was IBM's supports a GUI. Such an operating system is IBM's 
OS/2 with Presentation Manager (PM), but it will be 15 OS/2 with Presentation Manager (PM) on which the 
understood that the invention could be implemented on invention has been implemented, 
other and different operating systems and, more impor- The invention provides an open system which sup- 
tantly, could be integrated into, and therefore be a part ports and provides a consistent environment for a vari- 
of, an operating system. For more information on IBM's ety of unrelated application programs, as generally 
OS/2 operating system, the reader is referred to IBM 20 illustrated in FIG. 3. In FIG. 3, the Link Manager Sys- 
Operating Systems/2, Version 1 .2, Standard Edition Tech- terns (LMS) 31 is shown by way of example as support- 
nical Reference, IBM Corporation. ing five application programs including a spreadsheet 

Referring now to the drawings, and more particu- program 32, a word processing program 33, a motion 
larly to FIG. 1, there is shown a personal computer 10 video program 34, a graphical image program 35, and 
comprising a system unit 11, a keyboard 12, a mouse 13 25 an audio program 36. As will be described in more 
and a graphics display device or monitor 14. The key- detail hereinafter, the LMS 31 maintains via a database 
board 12 and the mouse 13 constitute user input devices, 37, stored for example on hard disk drive 26 (FIG. 2), 
and the display device 14 is a user output device. The various links specified by the user to each of the several 
mouse 13 is used to control a cursor 15 displayed on the application programs. 

screen 16 of the display device 14. The Graphic User 30 The database 37 is a collection of associations that 
Interface (GUI) supported by this system allows the LMS maintains. LMS was specifically and intentionally 
user to "point-and-shoot" by moving the cursor 15 to an designed to keep this information separate so as not to 
icon or specific location on the screen 16 and then press require the client applications to have to modify or 
one of the mouse buttons to perform a user command or corrupt their data in order to be an LMS participant 
selection. 35 This increases the openness of the LMS system. 

FIG. 2 shows in block diagram form the components There are basically two types of links which may be 
of the personal computer shown in FIG. 1. The system established. The first, illustrated in FIG. 4A, is a unidi- 
unit 11 includes a system bus 21 to which the various rectional link. This is a marker to object link. In FIG. 
components are attached and by which communication 4A, 41 and 42 represent windows in which various 
between the various components is accomplished. A 40 applications may be running. For example, in window 
microprocessor 22 is connected to the system bus 21 41, there may be displayed a text document generated 
and is supported by Read Only Memory (ROM) 23 and by a word processing program, an image generated by 
Random Access Memory (RAM) 24, also connected to a graphics program or a spreadsheet. A marker 43 may 
system bus 21. The microprocessor 22 in the IBM PS/2 be located at some point in the displayed document, 
series of computers is one of the Intel family of micro- 45 image or spreadsheet, and this marker 43 can be linked 
processors including the 80286, 80386 or 80486 micro- to an object in window 42. The linked object may be in 
processors, but other microprocessors including, but a text document, an image, a spreadsheet, audio, video, 
not limited to, Motorola's family of microprocessors slide show or any other application. The link is unidi- 
such as the 68000, 68020 or 68030 microprocessors and rectional since selecting the marker 43 will cause the 
various RISC (Reduced Instruction Set Computer) 50 linked object to be displayed in window 42, but there is 
microprocessors manufactured by IBM, Hewlett Pack- no return to the marker 43. 

ard, Sun Microsystems, Intel, Motorola and others may A bidirectional link is illustrated in FIG. 4B. This is a 
be used in a specific computer. marker to marker link rather than a marker to object 

The ROM 23 contains, among other code, the Basic link. Thus, for example, a marker 43 in window 41 may 
Input/Output System (BIOS) which controls basic 55 be linked to a marker 44 in window 42. Selecting 
hardware operations, such as interactions of the disk marker 43 will cause marker 44 in a text document, 
drives and the keyboard. The RAM 24 is the main mem- image or spreadsheet in window 42 to be displayed, 
ory into which the operating system and application Note that a marker can link to a marker in the same 
programs are loaded. A memory management chip 25 is application. For example, marker 45 in, for example, a 
connected to the system bus 21 and controls Direct 60 text document can be linked to another marker 46. As 
Memory Access (DMA) operations, including paging illustrated in FIG. 4B, the marker 46 may not be simul- 
data between RAM 24 and a hard disk drive 26 and a taneously visible with marker 45, but by selecting 
floppy disk drive 27. marker 45, that portion of the document in which 

To complete the description of the system unit 11, marker 46 is located is displayed. Likewise, when 
there are three I/O controllers. These are the keyboard 65 marker 46 is selected, that portion of the document in 
controller 28, the mouse controller 29 and the video which marker 45 is located is displayed, 
controller 30, all of which are connected to the system FIG. 5 shows in block diagram form the relation of 
bus 21. As their names imply, the keyboard controller the Link Manager Services (LMS) 51 to various client 
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applications 52. As will be described in more detail viewer 54 is used to graphically display the relation- 

hereinafter, the LMS 51 provides a uniform and consis- ships between documents, links and markers within the 

tent End User Interface (EUI). In particular, the LMS web database. The web viewer 54 is an LMS supplied 

51 performs several functions heretofore performed by client application having two types of capabilities: (a) 

the individual client applications. These include the 5 tools for . being able to see what associations exist 

generation of menus and dialog boxes which constitute amongst documents that have been registered with 

part of the EUL Thus, a specific client application will LMS, with varying amounts of scope (e.g., the entire 

issue a call to the LMS 51, and the LMS 51 generates web of applications, or *'zoom in" to just a few docu- 

the required menu or dialog box thereby assuring an ments, and (2) tools for web database administration and 

absolutely uniform and consistent EUI from client ap- 10 development. The database 53 is typically stored on the 

plication to client application. In addition, the LMS 51 hard disk drive 26 (FIG. 2), and the web viewer 54 

provides the EUI by which various of the client appli- produces the output screens to display device 14 (FIG. 

cations 52 may be launched. This will become clear 1). It should be understood, however, that the web 

from the following discussion with reference to the viewer is not the general presentation space and/or 

various drawing figures, but it should be understood 15 device provided by the underlying operating system, 

that the LMS 51 is a vehicle for accessing data which devices or LMS. Moreover, its use is not required in 

may have been generated by any one of the client appli- order for LMS to be used. The web viewer is a general 

cations and, when required, will automatically launch a utility application which is neither necessary for the 

client application in order to access data which has been practice or understanding of the disclosed and claimed 

linked to a marker. 20 invention and, therefore, is not described in more detail. 

FIG. 5 introduces a new concept and that is the no- The specific GUI environment in which the inven- 
tion of a *'web". The term "web" is used to refer to a tion is practiced is a windowing environment. The basic 
collection of document, link and link marker definitions. messaging set-up is common to most windowed sys- 
The web represents all the information required by terns, including OS/2 PM, Microsoft ® Windows and 
LMS to navigate the defined associations. The naviga- 25 X-Windows. Basically, every window in the system has 
tion can take the end user from a link marker in one what is called a window procedure associated with it. 
document to another application, to a document ren- When the operating system sends a message to a win- 
dered by a different application, to a margin note (au- dow, that message is routed to the window procedure 
dio, text, etc.), or to another location in the same docu- associated with that window. A window procedure is 
ment The target application can be one that is partici- 30 simply a piece of code provided by the application 
pating in the use of LMS or one that is not even aware which owns that window, and which knows how to 
of LMS. In other words, the use of the web allows LMS deal with certain types of messages. The usual messages 
to maintain all the necessary data about the associations that are sent from the operating system to a window are 
between documents without modifying the documents user input messages. Messages include things like button 
themselves. 35 presses, window activation, and the like. The window 

In one application, a web may be conveniently procedure of the window receiving the message can act 
thought of as a presentation system which utilizes sev- on the message or not act on the message. If the window 
eral client applications, such as a word processor, a slide procedure does not act on the message, there are certain 
show, an audio show and the like, to provide an end default procedures that might be called, 
user with multiple choices to access information on a 40 In the present invention, LMS makes use of the win- 
particular topic. Typically, the presentation of the topic dowing facility as well. In some places in the flow dia- 
is authored by a first type of end user of the system, say grams, arrows are shown going into the window proce- 
an instructor, and is viewed by a second type of end dure from both the operating system as user actions 
user of the system, say a student. Thus, the presentation from LMS as notification. That means that LMS is also 
of the topic to the student may begin by displaying an 45 sending notification messages to the application's win- 
initial window on the screen 16 of the display device 14 dow procedure. 

(see FIG. 1), and the student will typically have one or Referring now to FIG. 6 of the drawings, there is 
more link markers from which to select. The presenta- shown the logic of the client application window proce- 
tion then follows an arbitrary order depending on the dure according to the invention. This shows a window 
particular selections of the student. 50 procedure for a typical LMS enabled application, other- 
Using the example given above, when an end user is wise known as client application. The user does some 
reading a hypermedia document about nutrition and input (e.g., presses a mouse button, selects a menu, 
comes across a link marker, indicating that a Table of presses a key or a combination of keys, etc.) at operation 
Nutritional Values will be shown to the reader if the block 61, and the operating system sends that message 
link marker is triggered (e.g., activated via a pointing 55 to the client application's window procedure. When the 
device), and the reader activates the link marker, then client application's window procedure gets the mes- 
the Table is presented to the reader. If the reader had sage, it tests the message in decision block 62 to see if 
been using the document in hardcopy form (e.g., a the message is a command message (eg.; a menu com- 
book) then the reader might have had to search for the mand. message). If so, the application makes a further 
Table using the index or some other cross-reference 60 test in decision block 63 to see if it is one of the menu 
section of the document, and perhaps find multiple commands that it has defined; that is, is it one of the 
references for the Table, only one of which was for the menu commands that is pertinent to that application 
actual Table. regardless of LMS? These commands include open a 
To support this type of presentation, a web database new file, cut, paste, and other commands that are partic- 
53 is accessed by the LMS 51 in response to user selec- 65 ular to applications. If it is one of the menu options that 
tions of markers, or the entry of keywords, and present- the application itself has defined, then the application 
ers (i.e., applications, programs) are launched (started) will just go ahead and process the command in function 
by LMS 51 to render the required information. The web block 64 as if LMS did not exist. On the other hand, if 
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the command is not an application defined menu item, 
but it is a menu command, then the application will call 
the default LMS processing procedure in function 
block 65. This service is simply one function call, which 
is the LMS default processing procedure. Thus, if the 
application does not understand the menu command, 
then it will call the LMS service. 

Returning to decision block 62, if the command is not 
a menu command, then a test is made in decision blocks 
66 and 67 to see if it is some other type of message 
specific to the application. For instance, some applica- 
tions are interested in knowing if a mouse message came 
in. And if it did, as determined in decision block 66, the 
application would process it in function block 68 if that 



10 



clicked the mouse button over the client application's 
client or workspace area, near the top of the African 
continent. This context menu provides the user with 
several options, including creating a marker at that 
location. In FIG. 10, the user has clicked on the link 
marker. The context menu displayed is similar but offers 
different options (due to the different context), allowing 
the user to move or delete the marker, among other 
things. 

Client applications need not explicitly instruct LMS 
to build context menus, and in some cases (e.g., when 
the mouse is over a link marker as in FIG. 10) need not 
even forward any messages to LMS. Context menus, 
then, become almost a "free" feature of LMS, and pro- 



was the type of application that processes mouse mes- 15 vide access to the identical functionality of the pull- 



sages. Some applications do not process these messages, 
some do not need to, and typically whether an applica- 
tion processes that message or not, the application 
should call the default LMS procedure in function 
block 69 so that LMS has a chance to look at that mes- 
sage and to act on it accordingly. For instance, LMS 
might bring up a context menu. 

If command is not a mouse message, then the applica- 
tion determines in decision block 67 whether the mes- 



down menu. 

During client application initialization, the client 
application calls LMS requesting that the hypermedia 
pull-down menu be built. LMS will then dynamically 
20 build the menu so that the menu need not be defined in 
client application code, All subsequent processing of 
the menu (e.g., placing check marks next to menu items, 
disabling menu items, selecting menu items, etc.) is han- 
dled by LMS when LMS receives operating system 



sage is some other application specific message, and if 25 messages which the client application is not interested 



so, the application calls whatever function it calls to 
handle that message in function block 71. Otherwise, as 
with any message that the application does not know 
how to process, the application will call the LMS de- 
fault processing procedure in function block 72. 

In addition to messages generated by user inputs, 
LMS sometimes sends its own messages to client appli- 
cations, as indicated in function block 73, expecting to 
receive the message itself. Thus, LMS in one window 



in processing. 

All operating system messages not processed by the 
client application are forwarded to LMS by the client 
application using an LMS provided service. This in- 
30 eludes menu messages. Based on the particular menu 
message, LMS decides what needs to be done, and does 
it. For instance, if the message is that the hypermedia 
menu is about to be shown, then LMS will adjust the 
menu's appearance, if necessary, (e.g., disable all inap- 



might send a message to another window in the system 35 propriate menu options, etc.) based on the current state 
asking that window if it is aware of LMS, and the appli- of links and link markers, before showing it, or, if the 
cation in that other window would not understand the message was that "Create marker" was selected, LMS 
message. The message would not fall into the category will create a link marker for the end user without any 
of mouse message, menu command message or applica- additional work on the part of the client application. All 
tion specific message, and the application would there- 40 applications using LMS will have the same hypermedia 
fore not process the message and would call the LMS menus, arid the menus will behave in the same fashion, 
processing procedure. The LMS processing procedure thereby ensuring a consistent EUI. 
is aware of that message and will go ahead and return Examples are shown in FIGS. 11 to 15. More specifi- 
TRUE, "yes I am an LMS aware application". cally, FIG. 11 shows a pull-down menu when a mouse 

Having described the basic hardware and system 45 has been clicked on LINK in the action or command 
configuration, the operation of the LMS will be de- bar. 

scribed by way of example. FIG. 7 shows a computer Pull-down menus may be layered. For example, FIG. 
display screen produced by a Bitmap Displayer pro- 12 shows a second pull-down menu when a mouse has 
gram. This program is a presenter (i.e., application) been clicked on MANAGE MARKERS in the first 
which is rendering the GLOBE.BMP document (a 50 pull-down menu of FIG. 11, and FIG. 13 shows a third 



bitmap graphic). The GLOBE.BMP document contains 
a link marker (whose text says, "More info-*") which 
indicates the existence of associated information. When 
clicked on with the mouse, the link associated with the 
link marker will be navigated and the user will be pres- 
ented with the File Browser presenter rendering the 
WORLD TXT document (see FIG. 8). The 
WORLD.TXT document also contains a link marker 
(whose text says, "See a picture-*") which, if followed, 
would traverse to the GLOBE.BMP document. 

As mentioned, LMS also provides a consistent EUI 
by assuming the responsibility for generating menus. 
There are two types of menus; context menus (some- 
times referred to as pop-up menus) and pull-down 



pull-down menu when a mouse has been clicked on 
CREATE MARKER in the second pull-down menu of 
FIG. 12. A further example is shown in FIG. 14, which 
shows a second pull-down window when a mouse has 
55 been clicked on MANAGE LINKS in the pull-down 
window of FIG. 11, and FIG. 15, which shows a third 
pull-down window when a mouse has been clicked on 
CREATE LINK in the second pull-down window of 
FIG. 14. 

60 FIG. 16 is a flow diagram showing the logic of the 
pull-down menu processing. In order to get all those 
different menu items that are in that menu, LMS will 
actually build that menu for the client application, 
which also means that if in future releases of LMS addi- 



menus. The former are menus that are displayed de- 65 tional functionality is added, the client application will 
pending on the context or location of the cursor within not have to release a new version to inherit the addi- 
the field of the display. FIGS. 9 and 10 show examples tional LMS features, since LMS builds that menu. The 
of two types of context menus. In FIG. 9, the user has way LMS builds the menu is that when the application 
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first starts up, it calls LMS, through an LMS API func- 
tion call, and passes LMS a handle to its top level menu, 
usually the action bar, as indicated at function block 75. 
LMS then loads Us pull -down menu definition which 
has been saved as a resource as part of its dynamic link 
library in function block 76. When LMS loads the re- 
source, it will insert it, or attach it, into the client win- 
dow's menu handle in function block 77. From then on, 
when that menu option is selected by the end user, they 
will see all the LMS menu items in that menu. This 
procedure occurs at initialization time. 

The rest of the flow diagram of FIG. 16 illustrates 
how the actual pull-down menus are processed. Keep in 
mind that in LMS there are two types of menus. The 
pull-down menus are the menus that are displayed when 
the user selects the link from the action bar, while con- 
text menus are displayed in response to mouse clicks on 
the client window. Context menus are afforded similar 
options, but they are more specific to the object that the 
user has clicked on. Thus, what happens in the process- 
ing for these two types of menus is different. 

When a user action comes in, as indicated at function 
block 78, it goes to the application's window procedure, 
represented by function block 79. At that point, the 
application window procedure may determine that this 
is not a menu command that it knows (i.e., defined in the 
application code), so it passes the message to the LMS 
processing procedure (see FIG. 6). LMS determines in 
decision block 81 whether the message requires a menu 
to be shown. If so, in function block 82 LMS might 
enable some menu items that are applicable, disable ones 
that are not applicable, and/or check some items. Oth- 
erwise, a test is made in decision block 83 to determine 
if the message is a menu command message. If not, the 
"Non-Menu Command Message Processor" is called in 
function block 84. This procedure is described in more 
detail hereinbelow with reference to FIG." 18. If the 
message is a menu command, then LMS will go ahead 
and try to perform the appropriate action. For instance, 
there are certain messages such as save markers and 
links, password, and the like, that LMS will process. If 
the message is one that LMS will process as determined 
in decision blocks 85, 86 and 87, LMS notifies the client 
application of the forthcoming action in function block 
88 and then, if the application does not object to LMS 
performing the command as determined in decision 
block 89, LMS performs the function in function block 
90, notifies the application in function block 91, and 
returns a "TRUE" message in function block 92. Thus, 
if the message is one of those commands that LMS will 
process, LMS will perform the command, as discussed 
in more detail hereinafter. Then LMS notifies the appli- 
cation after it performs a command, and usually it 
supplies the application at that point also with a handle 
to the object that it just acted on so that the application 
can do some post -processing. 

If the message is a marker operation as determined in 
decision block 93, a further test is made in decision 
block 94 to determine if the marker is in a selected state. 
The marker must be in a selected state before a user can 
modify it from the command pull-down menu (although 
this is not true of context menus). Typically, those items 
which only act on objects which are not in a selected 
state are grayed out. For example, if there are no se- 
lected markers, then move marker would be grayed out, 
and the user would not be allowed to select it. If there 
are no markers selected, then modify marker would be 
disabled and the user would not be able to select that 
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command. This is different from context menus in that 
context menus simply omit items that are not applicable. 
In any case, LMS does provide code to double check to 
make sure it is okay to do some work. Therefore, if the 

5 menu command operates on a marker, it will first deter- 
mine whether or not there is at least one marker se- 
lected in a selected state and, if so, go ahead and do the 
appropriate marker command; that is, modify marker, 
create link, complete link, show markers, hide markers, 

10 etc. as determined by decision blocks 95, 96, 97, 98, 99, 
and 100. Create link and complete link are considered 
marker operations because they create a link emanating 
from a marker or complete a link to a marker. Once 
those commands are completed, the application is noti- 

15 fied that LMS performed a command and return true. 
Turning now to FIG. 17, there is shown a flow dia- 
gram which illustrates the logic of the context menu 
processing procedure 101. The process begins by first 
determining in decision blocks 102 and 103 what type of 
context menu LMS is supposed to display. The test in 
decision block 102 determines whether a doc. context 
menu is to be displayed, and the test in decision block 
103 determines whether a marker context menu is to be 

25 displayed. If LMS is supposed to display a doc. context 
menu, the resource definition of that menu is loaded in 
function block 104, and if LMS is supposed to display a 
marker context menu, the resource for the marker menu 
is loaded in function block 105. If neither a doc. context 

30 menu nor a marker context menu, an error message is 
returned in function block 106. 

Once LMS has loaded the menu, a hidden window is 
created in function block 107 which is actually going to 
own the menu that was just loaded. Then, in function 

35 block 108, the loaded menu is added to the new window 
and, in function block 109, the window is told to show 
-the menu. It should be understood that items in the 
menu will be removed, based on the state of the object, 
similar to when items are enabled and disabled from the 

4Q link pull-down menu. At this point, LMS waits for a 
user selection in function block 110. In decision block 

111, a determination is made as to whether or not the 
user actually canceled the menu or selected an item 
from the menu. If a menu item was actually selected, the 

45 command ID is returned, as indicated in function block 

112. Otherwise, a false is returned in function block 113. 
Now that the cases when LMS gets a user command 

^because menus have been selected have been discussed, 
what about other non-menu command processing? A 

50 generally available feature of most windowing systems 
is that of messages. Messages may be sent to an applica- 
tion from the operating system, another application, 
itself, or services operating on behalf of the application. 
These messages are notifications to the application of 

55 requests, responses to requests, actions performed, etc. 
Similarly, LMS uses this mechanism to allow client 
applications to optionally be aware of, qualify, limit, 
modify, or prevent actions that LMS is about to take. 
Additionally, LMS informs client applications via mes- 

60 sages after some actions have been taken. Both the "be- 
fore" as well as the "after" messages are sent regardless 
of whether the actions represented by the messages 
were initiated by the end user using the EUI, or by 
another client application, or by the client application 

65 itself Generally, the client application is free to ignore 
(pass through for default processing) these messages 
and will obtain the default (LMS) processing for them. 
But the opportunity to do otherwise is available. 
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For example, when LMS has been requested to show 
a pull-down or context menu, LMS sends the client 
application a message notifying it of same before any 
action is taken regarding the menu. The client applica- 
tion might want to disable/remove some item from the 5 
LMS menu before the menu is actually displayed. Simi- 
larly, when an LMS menu item is requested (e.g., to 
create a link marker), or the end user "clicks' 9 on a link 
marker thereby requesting that LMS navigate/follow 
to the other end of one or more of the link marker's 10 
"other ends", then a message is sent to that client appli- 
cation advising it of same. 

LMS provides a rich API by which client applica- 
tions may optionally exert control over the behavior 
and data of the LMS hypermedia system. In fact, in 15 
terms of functionality and capability, the LMS API is a 
significant superset of the LMS EUI, thus providing 
client applications with powerful capabilities and possi- 
bilities. More typically however, in order for a client 
application to be a significant participant as a hy- 
permedia participant, it only needs to make minimal use 
of the LMS API. 

Reference is made to FIG. 18 which is a flow dia- 
gram of the logic for the procedure for non-menu com- ^ 
mand message processing. Again, the user does some 
input at function block 115, and the operating system 
gives a message to the client application window proce- 
dure in function block 116. The window procedure will 
forward the message onto LMS in function block 117, 3Q 
as described previously. 

This processing procedure assumes that LMS has 
gotten past the testing to see if the message is a menu 
command. The other messages besides menu messages 
include mouse messages, messages from other windows 35 
that are sent to LMS from LMS itself (e.g., messages 
such as asking another application if it is an LMS aware 
application), etc. The non-message command message 
processor first checks in decision block 118 to see if 
mouse button three is pressed. If so, context menu pro- 40 
cessing is returned in function block 119 and, in decision 
block 121, a test is made to see if a command was en- 
tered by the user or if the user selected cancel. If a 
command was selected, then LMS does the basic pull- 
down menu processing, as indicated in function block 45 
122 and illustrated in FIGS. 16 and 17. Essentially, 
LMS executes the command with a notification to the 
client application, as described above. Remember that 
in the notation of the flow diagrams, every time "do 
'menu pull-down processing*" appears in a flow dia- 50 
gram, the process does not go to the top of the flow 
diagram shown in FIG. 16 for menu pull-down process- 
ing but, rather, enters at function block 88 of FIG. 16. 

Returning to decision block 118, if the mouse three 
button is not pressed, then a further test is made in 55 
decision block 123 to determine if the message is SHIFT 
key plus mouse button one. This is a way of creating a 
link and a marker. If so, LMS does that processing in 
function block 124. If not, a test is made in decision 
block 125 to determine if it is a command message. If so, 60 
a determination is made in decision block 146 as to what 
sort of command the command is. That is, is the com- 
mand one that LMS has defined as a command? If it is, 
a message is passed to the application in function block 
127. That message will again filter back down to LMS 65 
because the application will not want to process it, and 
then LMS will do its LMS command processing. If the 
message is not a command message, then LMS just 
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discards it in function block 128 if the message is not one 
that LMS understands. 

Referring back to decision block 125, if not a com- 
mand message, then a test is made in decision block 129 
to determine if the message is an LMS message; that is, 
is this an LMS specific message that LMS uses to com- 
municate with itself? LMS running on behalf of differ- 
ent processes that are using LMS might send these 
messages back and forth to communicate with each 
other without involving the client application. If it is an 
LMS message, one example of that type of message 
might be a query as to whether the application is LMS 
aware, as indicated by decision block 131. If not, when 
that other window gets this message, it will not have 
any LMS processing procedure to call. Therefore, that 
window would just return false, indicating that it does 
not understand the message. But if this message goes to 
an application that is LMS aware, it will return true, as 
indicated by function block 132. The message will get 
filtered down to the LMS processing procedure, as 
described before. If, in decision block 129, the message 
is not an LMS message, the message is discarded in 
function block 133. 

The end user interacts with objects on their screen by 
using the mouse. LMS manages mouse interactions with 
LMS objects (e.g., documents and link markers). LMS 
manages mouse actions in a number of ways. 

Client applications typically forward mouse messages 
to LMS. When LMS receives these mouse messages, it 
determines if some hypermedia-specific action needs to 
be taken. Using this mechanism, LMS is able to control 
the mouse when it is over the client application's "client 
window" (main application workspace). When a client 
application first displays a document, it notifies LMS of 
this, informing LMS of the name of document and the 
handle of the window in which the document is dis- 
played. LMS will then obtain, from the LMS database, 
all LMS objects associated with the document. LMS 
now has enough information to process mouse messages 
that occur in the client application's client area. This 
allows LMS to display context menus (see FIG. 9) over 
the client application's client window. When mouse 
messages get forwarded to LMS, LMS determines the 
state of the hypermedia objects (links, link markers, 
etc.) in the document, and can determine what types of 
items should be in the context menu (e.g., "Save mark- 
ers", "Hide markers", etc.). This facility is also used for 
the operation of making "quick" links, whereby the user 
can simply mouse click over two points (either within 
the same document, or different documents and present- 
ers) and have two link markers (one at each point) auto- 
matically created as well as the link between them. 
Typically, this is accomplished by the end user individ- 
ually creating two link markers, and then creating the 
link. The above functionality is all accomplished with- 
out the aid or knowledge of the client application, and 
will be consistent for all client applications which utilize 
LMS services. 

Since LMS link markers receive messages directly 
from the operating system, and the class of windows 
known to the operating system as "LinkMarker" is 
"owned" by LMS (i.e., the operating system invokes 
LMS code directly when a window of this type gets a 
message), mouse management over link marker win- 
dows is accomplished without the need for the client 
application to "forward" messages to LMS. 

When a link marker receives a message (from the 
operating system) that the mouse is over it, LMS will 
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change the mouse pointer appearance to indicate the from the link pull-down menu or from the context menu 

presence of a link marker to the end user (this is espe- displayed when the user clicks on the client workspace 

cially useful since markers may be "invisible", i.e., the in the client window of the application but not on a 

user* may interact with them, but cannot see them). marker. In the case of clicking on the client workspace, 

Additionally, this allows for LMS to handle many other 5 the action may be considered as clicking on a document, 

types of mouse activities over link markers, such as so the context menu is called a document context menu, 

"grabbing" a marker with the mouse and repositioning or simply a "doc. context menu". In any case, it is as- 

and/or resizing the link marker, displaying context sumed in the flow diagram of FIG. 19 that a create 

menus (see FIG. 9) for link markers, and viewing the command has come in from one of those sources, 

link marker's associated links. 10 The first thing that is done is that LMS captures the 

LMS also has the ability to manage the mouse when mouse in function block 136. That is a windowing term 

the mouse is over windows which do not use LMS meaning that control of the mouse pointer is obtained, 

services. One situation where this occurs is when end The mouse pointer is changed in function block 137 to 

users create link markers and links using "quick" link a different pointer shape to indicate that LMS is in the 

which is a fast path method for establishing links. In this IS process of marker creation. This shape is a tracking 

situation, the user simply presses a mouse button and rectangle that the user moves around the screen indicat- 

keyboard key while the mouse is over some part of a ing where they want to place the marker, 

client application's document, and then "drags" the Next, the process waits for operating system mes- 

mouse to another point (either in the same document, or sages in function block 138. This is done by inserting a 

another document/presenter) and releases the mouse 20 new message processing loop so that the application can 

button (if at any time during this operation the mouse is continue running, but LMS filters all messages before 

over an area which is not a valid link termination point, passing them to the application. Thus, function block 

the mouse pointer appearance will change to indicate 138 is a little loop called a get-message loop which 

this to the end user). This procedure allows link markers keeps looking for messages. Normally it is the applica- 

and a link to be established between the two points, all 25 tion itself that does that, but LMS exercises very tight 

in one step, The only client application participation control here. Every time a message comes in, LMS 

required during this processing is the forwarding of looks at it and determines in decision block 139 whether 

messages to LMS, as described above. this is a message that terminates this capturing of the 

LMS implements this functionality by using operat- mouse. If not, the message is dispatched to the client 

ing system services to obtain exclusive use of the mouse 30 application in function block 141; otherwise, the mouse 

(i.e., receiving all mouse messages, regardless of which capture is ended in function block 142. A test is then 

window the mouse is over). When the mouse button is made in decision block 143 to determine whether the 

released (to complete the operation), LMS queries the user canceled out of the marker creation process or did 

system to determine which window, if any, the mouse is they truly want to continue. If the user canceled out, the 

over. A message is then sent to that window to deter- 35 process is canceled in function block 144; otherwise, if 

mine if it is an application which uses LMS services. If the user wanted to continue, then a new "marker" is 

the window receiving the message uses LMS services, it created in function block 145. (The marker is an object 

need not (and will not) process this message, but will in the context which that term is used in object-oriented 

forward it to LMS which will respond that this applica- programming languages.) Then the actual marker ob- 

tion uses LMS services. If the target window of this 40 ject gets a new identification (ID) from the database in 

process is an application that uses LMS services, a link function block 146, and a marker window is created in 

marker will automatically be created for that applica- function block 147. This marker window is a visible 

tion at location of the mouse pointer, and a link will be manifestation of the marker, and whenever a window is 

established with the starting point of the operation. If created in a windowing system, a window procedure is 

the response to the message is that this application does 45 assigned to be associated with that window, as dis- 

not use LMS services, then a link will be established to cussed above. The window procedure for the marker 

that application, but no marker will be placed in it window function resides in the LMS dynamic link li- 

(LMS refers to these types of applications as "un- brary. That way, every time the marker is clicked on or 

aware"). any input comes to the marker, the link manager code is 

The end user may create link markers within the 50 executed, thereby effectively eliminating any client 

client application window, delete them, size them, application interaction. After the marker window has 

change their text, and change their appearance style. been created, it is then shown in function block 148. 

With the exception of marker creation and deletion Referring now to FIG. 30, the logic of the marker 

(which require the forwarded messages, as described window procedure is shown. In the context of this 

above), this can all be accomplished without any client 55 invention, a link marker may be conveniently thought 

application participation. Since LMS "owns" the link of as a window within an application window, and in 

markers (as described above and described in more fact that is what it is. The marker window procedure is 

detail below with reference to FIG. 20), LMS controls similar to the client application window procedure or 

the painting and positioning of the link marker win- any window procedure, and the code for the marker 

dows. Link markers may be made to invert the client 60 window procedure resides in LMS. Messages are input 

application data below them, which appears to the user by the user in function block 151 via the operating sys- 

as highlighting, however no processing is required of tern in function block 152 to the marker window proce- 

the client application to achieve the inverted area. dure in 153. When the marker window gets messages, 

Referring next to FIG. 19, there is shown a flow the marker window procedure checks for user indica- 

diagram of the logic of the create marker procedure of 65 tions of things it has to do. For instance, a test is made 

LMS. The process starts with a create command in in decision block 154 to determine whether button three 

function block 135. This means that one way or another, down. If mouse button three is down, then the marker 

the create marker command has been received, whether will display the marker context menu in function block 
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155 because, in the preferred embodiment of LMS, that 
is how a user brings up a context menu, by pressing 
buttons over a window. The context menu processor 
will return whether or not a command was actually 
selected from the context menu, as indicated in decision 5 
block 156. If a command was selected* then LMS essen- 
tially goes into the pull-down menu processing, as gen- 
erally indicated in function block 157 and illustrated in 
FIG. 16, starting at function block 88, and in FIG. 17. 
That is, LMS gives a notification message to the client 10 
application before actually executing the command in 
case the client application wants to prevent LMS from 
executing the command. LMS also sends the client 
application a message after executing the command. 
Anytime LMS internally is about to execute a com- 15 
mand, LMS always notifies the client application first 
with a special LMS message. And any time after LMS 
has performed a command, LMS always notifies the 
client application with a message saying LMS has per- 
formed the command. 20 

What if the user input is just a regular mouse click as 
determined in decision block 158? If it is, a further test 
is made in decision block 159 to determine if the mes- 
sage is a double click on mouse button one. If so, then 
the follow-link operation is performed in function block 25 
161. The C++ "marker object" knows all the links that 
are associated with it and all the information about ends 
of links, and all this information is stored in the database 
so LMS is able to do the follow link. On the other hand, 
if the message is a double-click on mouse button two, as 30 
determined in decision block 162, LMS will put up a 
dialogue box in function block 163 showing the user all 
the links that come out of the marker. 

If the mouse click is not any of those mouse click 
messages, then LMS checks to see if a control key was 35 
pressed at the same time the mouse button was down, as 
indicated in decision blocks 164 and 165. In that case, 
LMS does some direct manipulation work. Direct ma- 
nipulation means that the user presses a control key and, 
using the mouse, moves the marker in function block 40 
166 or sizes the marker in function block 167. 

Returning to decision block 158, if the message is not 
a mouse click, it is tested in decision block 168 to deter- 
mine if it is a paint message. If so, the marker closes its 
window to be repainted in function block 169. 45 

Referring next to FIG. 21, the flow diagram shows 
the logic of the window painting processing. The oper- 
ating system sends LMS a message in function block 
171, as in the other processes described. The message 
this time comes directly into the marker window proce- 50 
dure 172 because markers get messages without having 
to go through the client application first. The marker 
window determines in decision block 173 whether the 
message is a paint message. If it is a paint message, that 
is, the operating system is saying that the window must 55 
be redrawn, the marker determines in decision block 
174, by looking at the database, what the marker style is. 
There are two styles that are not transparent (i.e, you 
cannot see through them); one is called black and white, 
and is two dimensional, and the other is called push 60 
button, and which has a three dimensional appearance 
providing a visual depression movement when pressed. 
Any of the other styles, are transparent and are repre- 
sented in a screen print as a video inverse or high-light 
frame as illustrated, for example, in FIG. 22. 65 

If not a see-through type marker (i.e., a push button 
or a black and white), then the marker is painted in 
function block 175. But if it is a transparent marker 
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style, then the marker is hidden in function block 176; in 
other words, the whole marker window is removed 
from the screen. When the marker window is removed 
from the screen, the parent window below is told to 
repaint itself in function block 177. This assures that 
everything, all the data in the parent window, is current 
and up to date. As soon as that is done, the marker is 
reshown in function block 178, but the parent window 
is not repainted unless it is desired to paint the border or 
do an inverse. 

Under Microsoft ® Windows and OS/2 PM, there 
are no bits reserved on the pallet for transparency, so a 
window can not be made that a user can see through 
and that would be updated correctly and properly at all 
times. Windows and OS/2 Presentation Manager win- 
dows are opaque. Typically, when a window is created 
by an application, the window comes up on the screen; 
i.e., the operating system tells it to paint itself and it 
paints itself. Of course, in painting over any window, as 
by grabbing one window and putting it on top of an- 
other, what happens is that the operating system does 
not actually draw into the window; rather, the operat- 
ing system fills the window with a white background, 
text or whatever. This is illustrated, for example, in 
FIG. 23 which shows many different types of windows, 
scrollbars, icons, pushbuttons, etc. The operating sys- 
tem creates the window by reserving an area of the 
screen and, when the mouse is clicked there, the operat- 
ing system sends that window procedure messages, but 
the user is still able to see through the window to the 
window below it So what appears on the surface to an 
implementation of transparent windows is actually 
something as simple as a window not painting itself. 

Unfortunately, in practice, it is not quite that easy. If 
every time the operating system tells this new window 
that has been created to paint itself, one possibility is for 
the window to never paint itself, in order to be transpar- 
ent. However, it will not really be transparent. All that 
happens is that the bits on that area of the screen will 
not be painted. So if another window is brought on top 
of the "transparent" window and then moved off, the 
window that the "transparent" window is sitting on top 
of will repaint itself except in the areas where the 
"transparent" window is because windows never paint 
over other windows. And the "transparent" window is 
not going to paint itself. The bits that were on the screen 
will be the bits from the third window that were on top 
of both the "transparent" window and the window it 
sits on, so the screen is going to be incorrectly pres- 
ented. 

The solution to this problem is contained in the win- 
dow paint processing procedure shown in FIG. 21. 
Specifically, when that other third window is brought 
on top of our transparent window and then moved off, 
the operating system sends the transparent window a 
paint message. Rather than just totally not painting, 
what the window does is to recognize that the bits on 
this part of the screen are from that third window and, 
since that third window has moved away (as indicated 
by the receipt of the paint message), the transparent 
window must cause what is underneath to be shown. 
This is done by the transparent window hiding itself at 
function block 176 in FIG. 21. There are functions in 
the operating system to dp that. Th e parent window 
will then get a paint message from the operating system 
which the transparent window will teel the parent win- 
dow to act on immediately. At this point, the parent 
window will paint itself in function block 177. Windows 
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will never paint over another window that is visible but that appears to the end user as part of the client applica- 

will paint other screen areas if a window is not visible tion without any rewrite of client application code, 

(i.e.* hidden) in that screen area. So the procedure is to In any case, the dialogue box is displayed according 

hide a window and tell the parent window to paint itself to what object LMS is working on; whether it is a 

in this particular area where the transparent window 5 marker or a document or a link, etc. If the dialogue box 

was. In this way, the screen is all refreshed, up to date does modify objects based on user interaction with it, as 

and current. determined in decision block 184, then a message is sent 

Now, the transparent window must be shown again. to the application in function block 185 telling the appli- 

When the transparent window is shown again, the oper- cation that LMS is about to change something, at which 

ating system recognizes this and directs the window to 10 point the application responds in message block 186 

paint itself, but the transparent window will not paint whether it is okay to continue. If the application says it 

itself so that the end user can look through the transpar- is okay to continue, then LMS processes the command 

ent window to the data below! This all happens instanta- in function block 187 and notifies the application in 

neously and effectively produces transparent windows function block 188, as before. 

on the PM of OS/2. Again, transparent windows may 15 Returning to decision block 184, if the dialog box is 

do some painting if that is desired, like inverting the bits not going to modify an object, then LMS does not even 

that are in the rectangular region of the screen occupied bother asking the application if it should do this or not. 

by the transparent window to produce an inverse video Instead, LMS processes the command in function block 

highlighting or draw a wire frame on the boundaries of 189. 

the window as shown in FIG. 22. In FIG. 22, which is Finally, if the dialogue box is not used as determined 
a screen print that shows an inverse video highlighted by the test in decision block 182, a further test is made 
text, on the screen 14 (FIG. 1) it is not really high- in decision block 191 to determine if direct manipulation 
lighted text; it is actually a transparent window there. is needed. Direct manipulation, again, is grabbing mark- 
In addition to menus, another method of interaction ^ ers with a mouse, not selecting menu items; that is, just 
between an end user and an application is the use of using the keyboard and the mouse to select things and 
dialog boxes. Dialog boxes gather information needed grab them and do things to them, make links, etc., with- 
for particular tasks from the end user. LMS provides out any menus involved. If some sort of direct manipu- 
and manages all dialog boxes necessary for a client lation is needed, then LMS sends a message to the appli- 
application to provide full hypermedia support. FIGS. 3Q cation in function block 192. For instance, if the direct 
24, 25 and 26 give examples of some of the dialog boxes manipulation is to move a marker which, by the way is 
provided by LMS. More specifically, FIG. 24 shows an an item that a user could select from a pull-down menu, 
example of the dialog box used to prompt the end user LMS sends the application a message saying that it is 
to specify the style of a link marker. FIG. 25 shows an about to move the marker just as if the user had selected 
example of the dialog box used to prompt the end user 35 that function from a pull-down menu, so that the client 
to select a link for purposes of management; i.e., dis- application does not have to be sensitive to the method 
playing the link marker abstract, follow the link, etc. the user is using to perform these activities. As before, 
FIG. 26 shows an example of the dialog box to prompt LMS waits for the application to respond whether or 
the user to enter a keyword for purposes of a hy- not it should proceed. If the application responds that it 
permedia database search. 40 is okay to proceed, LMS processes the command in 
The client application need not call any LMS services function block 187 and then, as always, after processing 
in order to display or manage the dialog boxes; LMS the command, notifies the application in function block 
automatically provides this support. This ensures that 188. 

all applications using LMS services will provide a con- As is true of other areas of the LMS supplied EUI, 
sistent set of hypermedia dialog boxes, across client 45 although the client application is not required to pro- 
applications, vide any hypermedia support, they may modify, en- 
LMS contains the definitions (i.e., appearance/behav- hance, or prevent the displaying of the LMS supplied 
iors) of all dialog boxes. When the end user requests a dialog boxes. Additionally, services are provided for 
hypermedia service (typically using menus), LMS will client applications to display LMS dialog boxes at times 
begin executing the request. If during this execution it is 50 of their choosing, rather than only when LMS finds it 
determined that dialog boxes need to be displayed (e.g., necessary. 

more information is needed), LMS will display them. All information needed to support links between 
Since all of the hypermedia dialog boxes are concerned documents is maintained by LMS in a separate database 
with LMS objects (e.g., links, link markers, etc.), LMS known as a web (see FIG. 5). The files containing the 
is able to apply the end user's request to the object 55 client application's data need not be modified in order 
without the cooperation of the client application. for that application to utilize LMS services; rather, a 
FIG. 27 is a flow diagram of the logic of the dialogue conceptually parallel "view" or "overlay" of all of the 
box management. For each command that the LMS hypermedia objects is stored in the web database. The 
command processor 181 performs, such as create mark- client, application need not be concerned with the for- 
ers, create links, modify things, and the like, a test is 60 mat of this database nor with accessing the database; 
made in decision block 182 to determine whether a these concerns are handled entirely by LMS. This data- 
dialogue box is needed. If the answer is yes, then LMS base may be used in a single-user workstation environ- 
displays the dialogue box in function block 183. These ment, or a multiple workstation/user/process (e.g., 
dialogue boxes are stored with the LMS resources just network) environment permitting shared database ac- 
like menus; they are not stored with the client applica- 65 cess, including update. The LMS hypermedia objects 
tion. The whole user interface is stored with LMS, thus remain persistent (in the database) after the client 
which means it is modular so that if a new version of the application has ended, and they will be made available 
LMS is introduced, there will be a new user interface again when the client application is again used to render 
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its document(s). This design, which offloads much work 
from the client application, is described below. 

The hypermedia objects are documents, presenters, 
link markers, and links. LMS will save all new and 
modified hypermedia objects into the database, and 
remove all hypermedia objects from the database for 
which deletion has been requested, when requested to 
do so (either by the end user or the client application), 
as well as when the client application is closed (unless 
requested to not do so by either the end user or the 
client application). 

When a client application is rendering its data, object 
creation can be manifested in either or both of two 
ways: 

Hypermedia object previously existed in the data- 
base: When the client application identifies itself and its 
document to LMS, LMS automatically loads the rele- 
vant hypermedia object data from the database and 
displays the link markers appropriate for the portion of 
the document currently being displayed by the client 
application. 

Hypermedia object does not exist in the database: 
Presenter objects, which contain LMS data about the 
client application (e.g., its name), are automatically 
created by LMS whenever a client application first 25 
becomes known to LMS (i.e., when the client applica- 
tion "checks in" with LMS via the LMS API). The 
same is true for document objects. LMS creates link 
marker and link objects whenever requested to do so by 
either the end user (using the LMS EUI), and/or the 
client application (using the LMS API). Examples of 
the latter (LMS API) case might be heuristic or other 
artificial intelligence client applications; or utility pro- 
grams written to dynamically (i.e., without end user 
interaction) create documents, link markers, and link 
objects for previously existing (perhaps large) corpora 
of machine readable information, the format, content, 
and semantic associations of which are known or dis- 
coverable by the programs such that a highly useful, 
perhaps non-lineal, web database of hypermedia associ- 
ations would be obtained (e.g., machine maintenance 
information, encyclopedias, medical information, per- 
sonnel skills information, education courses which 
would permit structured learning and/or virtually peri- 
patetic discovery, sales/catalogue information, a dictio- 45 
nary, etc.). 

FIGS. 28 and 29 are flow diagrams pertaining to 
LMS database maintenance. The procedure illustrated 
in FIG. 29 is called from the procedure in FIG. 28. The 
database maintenance procedures are invoked when- 
ever the user of the hypermedia system creates, changes 
or deletes a document, link marker or link. In FIGS. 28 
and 29, references to lock and unlock when used in the 
context of database objects is intended to describe the 
scope of their availability to others. Lock means to 
obtain exclusive use, and unlock means to release exclu- 
sive use and thereby make available for others. There- 
fore, if one process locks an LMS document database 
object, then no other process can gain access to that 
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the database is. locked in function block 203, but in 
either case, a further test is made in decision block 204 
to determine if the document is to be deleted. If so, the 
process enters a first loop to identify and then remove 
the link markers belonging to the document. The loop 
begins with decision block 205 where a test is made to 
determine if this is the first or if there is another link 
marker belonging to this document. If so, the link 
marker is flagged for deletion in function block 206 and, 
then in procedure 207, the link marker and its links are 
removed from the database. This is done by calling the 
link marker and link database update procedure de- 
scribed in more detail with reference to FIG. 29 below. 
When a return is made from this procedure, the process 
loops back to decision block 205. 

If the test in decision block 205 indicates that there 
are no link markers or that all link markers have been 
flagged, the document is deleted from the database in 
function block 208. Then a test is made in decision block 
209 to determine if the document previously existed in 
the database. If so, the document lock is destroyed in 
the database in function block 210 before the procedure 
ends; otherwise, the database is first unlocked in func- 
tion block 211 before the procedure ends. 

Returning to decision block 204, assuming that the 
document is not to be deleted, a second loop is entered 
to identify link markers belonging to the document and 
then perform the update required. This loop begins with 
decision block 212 where a test is made to determine if 
this is the first or if there is another link marker belong- 
ing to this document. If so, a further test is made in 
decision block 213 to determine if the link marker is 
new, changed or deleted. If so, the procedure 214 is 
called to update the link marker and its links in the 
database. Procedure 214 is the same as procedure 207 
and, again, is described in more detail below with refer- 
ence to FIG. 29. When a return is made from procedure 
214 or if the link marker is not new, changed or deleted 
in decision block 213, the process loops back to decision 
block 212. 

When all the link markers have been identified and 
updated, the loop exists to decision block 215 where a 
test is made to determine if the document is new or 
changed. If so, the document object 'data is written into 
the database in function block 216. In either case, a test 
is next made in decision block 217 to determine if the 
document previously existed in the database. If so, the 
document is unlocked in the database in function block 
218 before the procedure ends; otherwise, the database 
is unlocked in function block ill before the procedure 
ends. 

Turning next to FIG. 29, when the link marker and 
link database update procedure is called at procedure 
207 or 214 in FIG. 28, a test is first made in decision 
block 221 to determine if the link marker exists in the 
database. If so, the link marker is locked in the database 
in function block 222; otherwise, the database is locked 
in function block 223. In cither case, a test is next made 
in decision block 224 to determine if the link marker is 
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object in the database until the object is unlocked. If a 60 to be deleted. If so, the procedure enters a first loop to 



process locks the (entire) LMS database, then no other 
process can subsequently gain access to any object in 
the database until the database is unlocked. 

Referring first to FIG. 28. the LMS database update 
procedure begins by testing in decision block 201 to 65 
determine if the document which is the subject of the 
update exists in the database. If it does, the document is 
locked in the database in function block 202, otherwise, 



identify the links attached to the link marker and then to 
delete those links. The loop begins with decision block 
225 where a test is made to determine if this is the first 
or if there is another link attached to the link marker. If 
so, the link's other-end link marker is locked in the 
database in function block 226. Then, the other-end link 
marker is read from the database, the link is detached 
from it, and the other-end link marker is rewritten in the 
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database in function block 227, The link's other-end link integer if it wants, saying this marker goes on line 5, 

marker is unlocked in the database in function block Now, LMS simply stores data away in the web data 

228, and the link is then deleted from the database in base with that particular marker object Now, next time 

function block 229 before the process loops back to that editor shows that document and tells LMS to load 

decision block 225. 5 up all the markers and links, LMS will go through each 

When all links have been identified, the loop exits to marker, enumerating the markers using the functions 
function block 230 where the link marker is deleted provided by LMS and, as it enumerates, for each 
from the database. Next, a test is made in decision block marker it will identify the user data associated with this 
231 to determine if the link marker previously existed in marker. In the example given, that is the same user data 
the database. If so, the link marker lock is destroyed in 10 that the application stored, and LMS will simply pro- 
function block 232 before the process ends; otherwise, vide the data that the application had stored. While 
the database is first unlocked in function block 233 be* LMS will not know what the data means, the applica- 
fore the process ends. tion will recognize it as meaning that this marker goes 

Returning to decision block 224, if the link marker is on line 5. At that point, the application can through the 

not to be deleted, the process enters a second loop to 15 API to reposition the marker or do whatever the appli- 

identify the links attached to the link marker and per- cation wants with it. 

form the required update. This loop begins with deci- The same is true for links. Links have the user data 

sion block 234 where a test is made to determine if this which behaves exactly the same as marker user data. An 

is the first or if there is another link attached to the link example usage of link user data might be the case where 

marker. If so, a further test is made in decision block 235 20 every time a link is established, the application wants to 

to determine if the link is new, changed or deleted. If so, keep information specific about what its state was when 

a test is made in decision block 236 to determine if the that link was created; e.g., whether an application has 

link is to be deleted. If so, the link's other-end link the ability to have or not have a title bar. What the 

marker is locked in the database in function block 237. application may want to do is to store that link user data 

Then the other-end link marker is read from the data- 25 (i.e., the fact that it does not have a title bar when the 

base, the link is detached from it, and the other-end link link was completed). At another time if it does have a 

marker is rewritten in the database in function block title bar, it might store in that link. Then when that link 

238. The link's other-end link marker is unlocked in the is followed and the application comes up and loads its 

database in function block 239, and the link is deleted document, the application checks the user data in this 

from the database in function block 240 before the pro- 30 link. The user data informs the application that when 

cedure loops back to decision block 234. If the link is this link was created, the application did not have a title 

not to be deleted but it is new or changed, the link bar, so the application hides its title bar, but when the 

object data is written to the database in function block other link is found, the application will find that the user 

241 before the process loops back to decision block 234. data here says that it did have a title bar, so a title bar is 

When all the links have been identified and updated, 35 displayed, 
the loop exists to decision block 242 where a test is LMS does not understand the user data; it's like a 
made to determine if a link marker is new or changed. If little note pad that applications can keep with each link 
so, the link marker object data is written to the database and each marker. Additionally, LMS has something 
in function block 243. In either case, a further test is called the user key with both links and markers which 
made in decision block 244 to determine if the link 40 are ways for applications to quickly son through and 
marker previously existed in the database. If so, the link filing a particular marker or particular link. It is a key, 
marker is unlocked in the database in function block 245 so if an application always wanted to access one panic- 
before the procedure ends; otherwise, the database is ular marker item but many markers were associated 
unlocked in function block 233 before the procedure with a document, perhaps thousands, the application 
ends. 45 could assign the marker a particular user key which is a 

While LMS provides a mechanism for off-loading long extra value. Most LMS functions take the user key 

work from client applications, it is not desirable to re- as a parameter, so if a user wanted to retrieve the first 

strict the client application. Sometimes when work is marker, LMS would just return the first marker that we 

off-loaded, the application can actually be restricted in find out of the whole set of markers. But if the user 

its functionality. That is why LMS always sends notift- 50 wanted to retrieve the first marker with the user key of 

cation messages before it acts on commands. 10, then LMS would do the searching through all the 

The client application is provided a way to store markers and determine which marker has a user key of 

information of its own liking with certain LMS objects, 10. 

such as markers and links in particular. For instance, if LMS provides for the deletion of hypermedia objects 

a text editor application has enabled itself with link 55 by the end user (using the LMS EUI), as well as by the 

manager services and it wants to know with what line client application (using the LMS API). When a link is 

number in its file the marker is associated, LMS does deleted from a link marker, LMS will automatically 

not understand client application data, so LMS does not remove its other end from the link marker to which the 

know what a line is. To solve this problem, an area is other end was attached. When a link marker is deleted 

provided in each LMS object, specifically markers and 60 from a document, LMS will automatically delete all of 

links, called user data, and APIs are provided to access the links attached to it. When a document is deleted, 

this area of data. Basically, this is an area LMS does not LMS will automatically delete all of the link markers 

understand the data stored there. It is an area where for that document. 

applications can store data. LMS does not look at the The attributes of documents, link markers, and links 

data since it is raw binary data and the application can 65 may be modified by the end user (using the LMS EUI) 

store whatever it likes there. For instance, if an applica- and/or the client application (using the LMS API). For 

tion knows a marker belongs on line 5 f then the applica- example, the style, size, location, etc. of a link marker 

tion can set some structure in the user data, or just one may be changed using these facilities. 
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Since all of the information regarding link markers, as a courtesy to the end user who is probably more 

links, documents, and presenters is kept in a database interested in reading the descriptive text first, 

managed by LMS, LMS is able to determine which LMS provides a consistent end user interface across 

presenter to launch with which document when the end all client applications for hypermedia menus, dialog 

user attempts to follow a link. Since link markers get 5 boxes, mouse processing, and link marker display man- 

and process their own messages with no client applica- agement. These facilities not only provide for the ap- 

tion interaction (see the "Mouse processing" above), pearance of these notions, but also result in the execu- 

LMS can determine where links go (e.g., presenter P is tion of code to scmantically satisfy the end user's re- 

to render document D positioned, if necessary, to link ques t The functional relationship between LMS and an 

marker M) by querying the database, and, since LMS 10 application and the EUI is illustrated, by way of sum. 

has the ability to launch (start) applications, LMS ena- mar y ( m FIG. 30. The user may input commands, i.e., 

bles end users to follow links without requiring any messages, in a variety of ways, as indicated by block 

client application participation whatsoever. 284. These include a mouse, keyboard or LMS menus. 

Even though LMS goes to great lengths to offload messages may first of all ^ , t tQ m application 

almost all of the work needed to provide hypermedia 15 rogram ^ m application window m ^ mcs . 

support (and hence reduce client application coding ^ m d t0 the m proces sing code of the 

effort and development time), it is not desirable to pre- application m ^ if Ae app i ication ^ses not to 

vent chent applications from being able to exert control s the m it is then sent t0 the m 

over the behavior and data modifications of he hy- cessing code of the LMS 287. An example is the genera- 
ted* system. LMS provides this controUabdity 20 ^ of ^ ^ ^ 
through messages and Application Programming Inter- Qthcr ^ ^ mes J ges may ^ LMS messages, in 

tace (Ar ). %#c u v ~ * i which case the message is passed directly to the LMS 

As previously mentioned, the LMS push-button style a„ i v ...S™ « i t _ t, • i * j 

- ,. , , , ^ . . r . . , . 287. An example is when a link marker is selected, 

of link marker has two substyles, one, which is three ^ • . u v a j • : 

dimensional" in appearance L has visual depression- 25 J^^^S^^j!^^ ™ *T of " 

movement when jessed," and another, known as s "?,f e Mbodimem, those skJled m the art 

"black and white," which is two dimensional in appear- ™" ? co f ? mzc * al ' h v e ,nve .f °" can * P r ? ct,ced ™* 

ance. Both of these can optionally be made to contain •modification within the sp.nt and scope of the appended 

text which would briefly describe that information 

which would be obtained if one or more of the link 30 Having thus described our invention, what we claim 

marker's links were to be navigated (traversed). There- 35 new and desire t0 secure b V Patent ls fo1 ' 

fore the link marker's text, if present, can be thought of ,ows ; 

as a mini-abstractofthe information located at the other . ]; ? n an °P e , n hypermedia system in which data for 
end of the link marker's links. mdmdual applications may be displayed on a screen of 
In addition to the text contained in a link marker, 35 a d J s P lav device in separate application windows for 
LMS implements a link marker abstract object which is wch of said applications, each of said application win- 
owned by the link marker. The link abstract data is dows including a main application workspace in which 
defined to be summary text information about the infor- 531(5 data 1S displayed, a method performed by said hy- 
mation that can be found at the location of the owning permedia system and providing a uniform and consis- 
link marker. Thus, when LMS presents a list of candi- 40 tent graphical user interface for applications which 
date target link markers to the user (either as a result of utlllze hypermedia services available from said open 
the user "clicking" on a link marker with more than one hypermedia system, said method presenting, indepen- 
link emanating from it, or as the result of performing a dent of said applications, a menu of selectable hy- 
link marker abstract search, each candidate target link permedia services to a user and comprising the steps of; 
marker will be represented in the list by one of the 45 establishing an awareness between said hypermedia 
following: (1) the target's short abstract text, but if none ?y s *«n and an application upon application initial- 
exists then (2) the target's parent document name, but if ization; 

none exists then (3) the target's presenter name. There* monitoring a current position of a user controlled 
fore, having at least short abstract data for a link marker pointer on said display device; and 
can be useful for providing meaningful distinctions for 50 responsive to a first input by a user and said current 
the end user when displaying a list of candidate naviga- position of said pointer, displaying a menu of ac- 
tion targets, as well as for use in searching. The link lectable services appropriate to a current position 
marker abstract object, if it exists, consists of up to two of said user controlled pointer within an appiica- 
text parts, the short and long abstract text, either or tion window. 

both of which may exist. 55 2. The method recited in claim 1 further-comprising 

The link marker abstract short text data is intended to the step of sending a message to said application indicat- 

be brief descriptive text suitable for display on one line. ing receipt of a request for execution of said selected 

The link marker abstract long text data is intended for service. 

use when it is desirable to provide more voluminous 3. The method recited in claim 2 further comprising 
information about the information that can be found at 60 the step of receiving a message from said application if 
the owning link marker location. This text can be as the application requests said hypermedia system to pro- 
much as several tens of thousands of characters, more cess said selected service. 

for some national language characters sets. The long 4. The method recited in claim 1 wherein said user 
abstract text will only be presented to the end user upon controlled pointer is a cursor on the screen of said dis- 
request, but it will always be examined during abstract 65 play device, said window further including an action 
searches. If it is desirable, in anticipation of searches, to bar, wherein said step of displaying a menu comprises 
specify keywords not otherwise in the text, a guideline the step of displaying a pop-down menu having select- 
would be to place them at the end of the long abstract able services corresponding to a command in said action 
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bar when said cursor is positioned over said command 
at the time of said user input. 

5. The method recited in claim 1 wherein said user 
controlled pointer is a cursor on the screen of said dis- 
play device wherein said step of displaying a menu 5 
comprises the step of displaying a context menu having 
selectable services according to a location of said cursor 
within said main application workspace at the time of 
said user input. 

6. The method recited in claim 1 wherein said user 10 
controlled pointer is a cursor on the screen of said dis- 
play device, said window further including an action 
bar, wherein said step of displaying a menu comprises 
the steps of: 

displaying a pop-down menu having selectable ser- 15 
vices corresponding to a command in said action 
bar when said cursor is positioned over said com- 
mand at the time of said user input; or 

displaying a context menu having selectable services 
according to a location of said cursor within said 20 
main application workspace at the time of said user 
input, said pop-down menu and said context menu 
having a uniform and consistent format indepen- 
dent of said application. 

7. The method recited in claim 1 further comprising 25 
the step of displaying a dialog box on said screen for 
receiving additional user input in response to a selection 
by the user of a service from a menu when additional 
information is required in order to process a selected 
service. 30 

8. The method recited in claim 7 wherein said dialog 
box provides the user with the option to modify an 
object displayed on said screen, further comprising the 
steps of: 

receiving a user input to modify an object; 35 
passing a message to the application that said hy- 
permedia system intends to process the user input 
to modify said object; and 
processing the user input if the application accepts 
said message. 40 

9. The method recited in claim 8 further comprising 
the step of notifying the application when the user input 
has been processed. 

10. In an open hypermedia system in which data for 
individual applications may be displayed on a screen of 45 
a display device in separate application windows, each 
of said windows including a main application work- 
space in which said data is displayed, said hypermedia 
system providing a uniform and consistent graphical 
user interface for applications which utilize hypermedia 50 
services available from said open hypermedia system, 
said method performed by said hypermedia system and 
comprising the steps of: 

displaying on said screen a first link marker within an 
application window, said link marker being linked 55 
to one or more link markers and/or objects; 
maintaining a database of said link markers; and 
in response to activation of said first link marker by a 
user, searching said database and displaying on said 
screen a link marker or object linked to said first 60 
link marker. 

11. The method recited in claim 10 wherein said first 
link marker is linked to a plurality of link markers and- 
/or objects, further comprising the step of displaying on 
said screen a representation of said links and prompting 65 
said user to select a link to be navigated. 

12. The method recited in claim 11 further comrising 
the step of navigating a user selected link to display on 
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said screen a link marker or object linked to said first 
link marker. 

13. The method recited claim 10 wherein a second 
link marker or an object linked to said first link marker 
are within data of a second application further compris- 
ing the step of displaying on said screen said data in- 
cluding said second link marker or said object within an 
application window for said second application. 

14. The method recited in claim 13 wherein if said 
second application is not currently running, further 
comprising the steps of: 

launching said second application; and 
opening an application window on said screen for 
said second application. 

15. The method recited in claim 10 wherein said link 
markers are windows containing data of an application 
of said hypermedia system. 

16. The method recited in claim 15 wherein said link 
markers may be either opaque or transparent. 

17. The method recited in claim 15 wherein a user 
controlled cursor having a default shape is displayed on 
the screen of said display device, said method further 
comprising the steps of: 

monitoring a current position of said cursor on said 
display device; and 

changing said default shape of said cursor to a second 
shape denoting a link marker whenever said cursor 
is moved over a link marker on said display device. 

18. Trie method recited in claim 17 wherein a link 
marker may have a transparent attribute and the chang- 
ing of the default shape of said cursor to said second 
shape identifies the presence of a link marker at the 
location of said cursor. 

19. The method recited in claim 10 wherein a user is 
provided with options for creating, editing or deleting 
link markers. 

20. The method of claim 19 further comprising the 
steps of: 

establishing links from a link marker to another link 
marker or an object when a link marker is created, 
links between a link marker and another link 
marker being bidirectional and links between a link 
marker and an object being unidirectional; 

changing attributes of a link marker including links 
when a link marker is edited; and 

deleting all links to a link marker when a link marker 
is deleted. 

21. In a windowing computer display in which data 
from one or more applications may be displayed in 
separate windows, said windows being individually 
movable on a screen of said computer display in such a 
manner windows may overlay one another and nor- 
mally obscure portions of underlying windows, the 
method of supporting transparent windows on said 
display screen comprising the steps of: 

allocating an area on said screen for a window; 

checking said window for a transparent attribute; 

painting said window on said screen if said transpar- 
ent attribute is not detected; but 

if said transparent attribute is detected, hiding said 
window and then, if said window overlies a second 
window, repainting said second window. 

22. The method recited in claim 21 further compris- 
ing the step of showing a boundary of said transparent 
window by a highlight without obscuring data in a 
window below said transparent window. 

23. The method recited in claim 21 wherein a cursor 
is movable on said screen under user control and further 
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comprising the step of changing a shape of said cursor action bar when said cursor is positioned over said 

within said . area of said transparent window to indicate command at the time of said user input; and 

the location of said transparent window, means for displaying a context menu having select- 

24. The method recited in claim 21 wherein said able services according to a location of said cursor 
transparent window overlies said second window and a 5 within said main application workspace at the time 
third, non-transparent window at least partially overlies 0 f said user input, said pop-down menu and said 
said transparent window, further comprising the steps context menu having a uniform and consistent for- 

mat independent of said application. 

moving said third window so as not to overlie said 31, The method of claim 25 further comprising means 

transparent window; and 10 for displaying a dialog box on said screen for receiving 

repainting said second window in that area where additional user input in response to a selection by the 

said thrid window formerly overlied said second ^ of 8 from a menu when additional informa- 

window including the area of said transparent win. tion is require d in order to process a selected service. 

dow * , Jt , , 32. The method of claim 31 wherein said dialog box 

25. An open hypermedia system in which data for 15 provides ^ ^ ^ the option to modif m object 

individual applications may be displayed on a screen of displayed on said screen, further comprising: 

a display device in separate apphcation windows for means for living a user input to modify an object; 

each of said apphcations, each of said application win- mcans for m a m to ^ application that 

dows including a main application workspace in which ^ hypermedia system mimds %Q ^ ^ ^ 

said data is displayed, said hypermedia system jrovid- 20 . tQ modif ^ obj mA 

ing a uniform and consistent graphical user interface for means for processing ^ user mput if ^ application 

apphcations which utilize hypermedia services avail- u J\, mgs * p ™ 

able from said open hypermedia system said hy- 33 ^ hypennedi / svstem recited m claim 32 ^ 

permedia system presenting independent of said apph- ^ ^ m eans for notifying the application 

cations a menu of selectable hypermedia services to a 25 when * f has > J ™ 

user and comprisine: _ . . x r * 

means for establishing an awareness between said . h ^^ia^stem m which data for 
hypermedia system and an application upon appli- ^dividual applications may be displayed on a screen of 
cation initialization- a display device in separate application windows, each 
means for monitoring a current position of a user 30 of said wi " d ° ws ™! udin * a ^ain application work- 
controlled pointer on said display device; and s P ace m whlc ji dat * IS d «played, said hypermedia 
means responsive to a first input by a user and said svstem Providing a uniform and consistent graphical 
current position of said pointer for displaying a user mterfa « \ f ™ applications which utilize hypermedia 
menu of selectable services appropriate to a current available from said open hypermedia system, 
position of said user controlled pointer within an 35 ^ hypermedia system comprising: 
application window. means for displaying on said screen a first link marker 

26. The hypermedia system recited in claim 25 fur- Wltmn ™ application window, said link marker 
ther comrpising means for sending a message to said ^8 lmked t0 one or more hnk markers and/or 
application indicating receipt of a request for execution objects; 

of said selected service. 40 means for maintaining a database of said link markers; 

27. The hypermedia system recited in claim 26 fur- 

ther comprising means for receiving a message from means responsive to activation of said first link 

said application if the application requests said hy- marker by a user for searching said database and 

permedia system to process said selected service. displaying on said screen a link marker or object 

28. The hypermedia system recited in claim 25 45 hnked to said first link marker. 

wherein said user controlled pointer is a cursor on the 35 - The hypermedia system recited in claim 34 

screen of said display device, said window further in- wherein said first link marker is linked to a plurality of 

eluding an action bar, wherein said means for displaying hnk markers and/or objects, further comprising means 

a menu comprises means for displaying a pop-down for displaying on said screen a representation of said 

menu having selectable services corresponding to a 50 hnks and prompting said user to select a link to be navi- 

command in said action bar when said cursor is posi- gated. 

tioned over said command at the time of said user input. 36. The hypermedia system recited in claim 35 fur- 

29. The hypermedia system recited in claim 25 ther comrising means for navigating a user selected link 
wherein said user controlled pointer is a cursor on said to display on said screen a link marker or object linked 
display device wherein said means for displaying a 55 to said first link marker. 

menu comprises means for displaying a context menu 37. The hypermedia system recited in claim 34 

having selectable services according to a location of wherein a second link marker or an object linked to said 

said cursor within said main application workspace at first link marker are within data of a second application 

the time of said user input, said pop-down menu and further comprising means for displaying on said screen 

said context menu having a uniform and consistent for- 60 said data including said second link marker or said ob- 

mat independent of said application. ject within an application window for said second appli- 

30. The hypermedia system recited in claim 25 cation. 

wherein said user controlled pointer is a cursor on said 38. The hypermedia system recited in claim 37 
display device, said window further including an action wherein if said second application is not currently run- 
bar, wherein said means for displaying a menu com- 65 ning, further comprising: 

prises: means for launching said second application; and 

means for displaying a pop-down menu having select- means for opening an application window on said 

able services corresponding to a command in said screen for said second application. 
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39. The hypermedia system recited in claim 34 
wherein said link markers are windows containing data 
of an application of said hypermedia system. 

40. The hypermedia system recited in claim 39 
wherein said link markers may be either opaque or 
transparent. 

41. The hypermedia system recited in claim 40 
wherein a user controlled cursor having a default shape 
is displayed on the screen of said display device! said 
hypermeida system further comprising: 

means for monitoring a current position of said cursor 

on said display device; and 
means for changing said default shape of said cursor 

to a second shape denoting a link marker whenever 

said cursor is moved over a link marker on said 

display device. 

42. The hypermedia system recited in claim 41 
wherein a link marker may have a transparent attribute 
and the changing of the default shape of said cursor to 
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separate windows, said windows being individually 
movable on a screen of said computer display system in 
such a manner windows may overlay one another and 
normally obscure portions of underlying windows, said 
windowing computer display system supporting trans- 
parent windows on said display screen and comprising: 
means for allocating an area on said screen for a win- 
dow; 

means for checking said window for a transparent 
attribute; and 

means for painting said window on said screen if said 
transparent attribute is not detected; but 

if said transparent attribute is detected, said means for 
checking hiding said window and then, if said win- 
dow overlies a second window, said means for 
painting repainting said second window. 

46. The windowing computer display system recited 
in claim 45 further comprising means for showing a 
boundary of said transparent window by a highlight 



said second shape identifies the presence of a link 20 without obscuring data in a window below said trans- 
marker at the location of said cursor. parent window. 

43. The hypermedia system recited in claim 34 47. The windowing computer display system recited 
wherein said hypermedia system provides a user with in claim 45 wherein a cursor is movable on said screen 
options for creating, editing or deleting link markers. under user control and further comprising means for 

44. The hypermedia system recited in claim 43 fur- 25 changing a shape of said cursor within said area of said 
ther comprising: transparent window to indicate the location of said 

means for establishing links from a link marker to transparent window, 
another link marker or an object when a link 48. The windowing computer display system recited 
marker is created, links between a link marker and in claim 45 wherein said transparent window overlies 
another link marker being bidirectional and links 30 said second window and a third, non-transparent win- 
between a link marker and an object being unidi- dow at least partially overlies said transparent window, 
rectional; further comprising means for moving said third win- 
means for changing attributes of a link marker inchid- dow so as not to overlie said transparent window, said 
ing links when a link marker is edited; and means for painting thereafter repainting said second 
means for deleting all links to a link marker when a 35 window in that area where said thrid window formerly 
link marker is deleted. overlied said second window including the area of said 

45. A windowing computer display system in which transparent window. 

data from one or more applications may be displayed in • * • * * 
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